Problem

extract_via_sqlite (the recovery path rebuild_from_sqlite uses when the chromadb collection layer itself is broken, e.g. the #1308 HNSW-segment failure) drives its extraction with an INNER JOIN that starts at embedding_metadata:

FROM embedding_metadata em
JOIN embeddings e ON em.id = e.id
WHERE e.segment_id = ?

Any embedding with zero rows in embedding_metadata — a sparse historical write with no chroma:document key and no other key — never appears in the join result at all, so it is silently dropped.

This condition is not hypothetical: the sibling extractor _extract_drawers (used by the collection-layer rebuild_index path) already sanitizes for it directly in its own comments — "drawers extracted from sqlite ground truth can come back with None or {} for sparse historical writes" (#1458). extract_via_sqlite has no equivalent handling, because such rows are structurally invisible to a join anchored on embedding_metadata.

Running mempalace repair --mode from-sqlite --archive-existing on a palace containing any such drawer drops it with no count mismatch and no warning.

Fix

Drive the query from embeddings (LEFT JOIN embedding_metadata) instead, defaulting to an empty metadata dict when a row has none. Order by e.id rather than em.id, since em.id is NULL for the now-included unmatched rows.

Tests

One new regression test in tests/test_repair.py: seeds a real chromadb collection via the existing _seed_palace helper, then strips one drawer's embedding_metadata rows directly via SQLite (current chromadb validates against empty metadata on write, so this only reproduces on rows already sitting in an older palace) and asserts the drawer still comes back through the SQLite bypass. Confirmed failing against the pre-fix code, passing after the fix. All 97 existing tests in tests/test_repair.py still pass.